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REMARKS 

Claims 1,4-18 and 21-32 are pending. 

Claims 31-32 are withdrawn from consideration. 

Claims 1,4-18 and 21-30 are rejected. 

The office action dated 31 July 2009 indicates that claims 1,4-18 and 21-30 are 
rejected under 35 USC §1 03(a) as being unpatentable over Gupta U.S. Patent No. 
6,405,308 in view of Cookson U.S. Publication No. 2004/0083239 and in further view 
of Official Notice. The '103 rejection is respectfully traversed. 

The present application describes a product definition as a collection of 
components for different possible configurations of a product and that also provides 
details as to how the components are defined, developed, and manufactured. For 
example, Figure 8 illustrates a product definition 800, which includes components and 
details for different configurations in an aircraft family. 

The product definition can be used to create a deliverable configuration. A 
product configuration specification is applied to the product definition. The product 
configuration specification is a filter composed of selected options. When applied to 
the product definition, a deliverable configuration is produced. For example, Figure 9 
illustrates a result of applying a product configuration specification 902 to the product 
definition 800. 

Base claim 1 recites a method of creating a product definition. The method 
includes: 

creating instancings of one or more usage-based product definition 
inputs, the inputs including components and engineering requirement callouts 
for the different configurations; 

assessing applicability expressions, engineering requirements, and 
manufacturing availability to determine which instancings are available and valid 
for the different configurations; and 



-2- 



USSN 10/699,265 



generating the product definition based on all instancings that are valid 
and available. 

Base claim 21 recites a method of creating an air vehicle definition that 
describes a collection of components for different possible configurations of an air 
vehicle and also details how the components are defined, developed, and 
manufactured. The method includes: 

instancing a usage-based fuselage definition input, the usage-based 
fuselage definition input including at least one of a fore body definition input, a 
mid body definition input, an aft body definition input, a wing definition input, a 
vertical tail definition input, and a horizontal tail definition input; 

instancing a usage-based propulsion system definition input; 

assessing an applicability expression, an engineering requirement, and a 
manufacturing availability expression associated with at least some of the 
definition inputs; and 

generating the air vehicle definition based on the definition inputs, 
applicability expressions, engineering requirements, and manufacturing 
availabilities. 

The methods of base claims 1 and 21 improve upon the industry-old practice of 
defining products in terms of engineering assemblies and defining end-item product 
usage of an assembly on an external bill of material or on drawing sheets (see the 
Background). The methods of claims 1 and 21 allow for rapid and efficient option- 
based changes in the product configuration process. They can reduce errors, improve 
consistency and decrease product configuration time (see Summary). 

The methods of base claims 1 and 21 are not taught or suggested by Gupta or 
Cookson. Gupta discloses a system for interactively selecting and configuring a 
product of a product line based on availability and compatibility of features and options 
(Abstract). Gupta describes a maintenance system 202 for creating a product 
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definition. The maintenance system 202 maintains a parts catalog 204, parts 
relationships 206 and product definitions 208 (col. 5, lines 55-63). 

The product definition 208 is generated by population of a product with its 
component parts (col. 7, lines 26-35). Parts in a product definition 208 are related or 
classified. Part-to-product relationships include "included parts", "required choices" and 
optional parts" (col. 2, lines 25-26 and col. 6, lines 22-31). Part-to-part relationships 
include "requires," "choice," "includes," "can't work with," etc. (col. 6, lines 22-31 ). 

Gupta doesn't teach or suggest a product definition that describes a collection of 
components for different possible configurations of a product and also provides details 
as to how the components are defined, developed, and manufactured. Gupta's 
product definition 208 is little more than a collection of parts 204 and relationships 206. 

Gupta does not teach or suggest inputs to a product definition that include 
engineering requirement callouts. 

Gupta does not teach or suggest assessing applicability expressions, 
engineering requirements and manufacturing availability as part of creating a product 
definition 208. All of Gupta's assessments are performed during configuration of a 
desired product, not to create the product definition 208. Gupta describes a user 
configuration system 212 for allowing a user to select parts for a desired configuration 
(col. 2, lines 52-62). The configuration system 212 evaluates the current state of a 
configuration based on the product definition, parts relationship and state information 
(col .2, lines 63-65). 

Cookson is no more relevant than Gupta. Cookson also describes a system for 
allowing a user to select and configure a product. Configuration definitions 102 are 
built from a framework 110 that may include variables, items, formulas and assemblies 
(paragraph 15). A formula represents a data structure (paragraph 18). The variables, 
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items, formulas and assemblies represent generic features that may be selected for 
one or more articles. They also include operating logic for selecting specific features. 

Packets are formed from one or more assemblies, including items, variables, 
formulas and operating logic (paragraph 19). The packets include all of the information 
and logic of one or more assemblies corresponding to a type of article (paragraph 20). 
The packets are stored in a generalized object repository, which provides a 
generalized standardization of those articles (paragraph 21). 

A logic engine obtains user information and correlates that information with the 
variables, items and formulas to identify specific generic properties of an article 
specified by the user (paragraph 23) Generic properties of a computer, for example, 
would include processor type and speed, memory size, and hard drive size (paragraph 
24). 

The generic properties are correlated with specific article properties to 
determine whether the user wants an article in a catalog or whether the article has 
custom features (paragraphs 25-27). For example, Cookson's system can be used to 
help an online customer find an advertised computer or it can specify a computer 
having certain custom features. 

Cookson doesn't teach or suggest a product definition that describes a 
collection of components for different possible configurations of a product and also 
provides details as to how the components are defined, developed, and manufactured. 
Cookson's product definition 208 is little more than a collection of assemblies and 
relationships (logic). 

Cookson does not teach or suggest inputs to a product definition that include 
engineering requirement callouts. 
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Cookson does not teach or suggest assessing applicability expressions, 
engineering requirements and manufacturing availability as part of creating a collection 
of components for different possible configurations (that is, a product definition). All of 
Cookson's assessments are performed to configure a specific product, not to create 
the packets that are stored in the generalized object repository. 

Thus, the combined teachings of Gupta and Cookson do not produce a method 
having all of the features of base claim 1 or base claim 21 . Therefore, the '1 03 
rejection of base claims 1 and 21 should be withdrawn. 

Page 4 of the office action alleges that component types constitute engineering 
requirements. However, claim 1 does not merely recite engineering requirements. It 
recites engineering requirement callouts. Neither Gupta nor Cookson discloses 
engineering requirement callouts . 

Page 4 of the office action seems to acknowledge that neither Gupta nor 
Cookson discloses engineering requirement callouts . However, the office action takes 
Official Notice that callouts are well known and have been used on engineering 
drawings and specifications. However, the office action does not explain why it would 
be obvious to incorporate engineering requirement callouts in either Gupta's or 
Cookson's system (neither of which relies on engineering drawings). The office action 
only provides a bald conclusion of obviousness. Therefore, the '103 rejection does not 
comply with MPEP 2142. 

Page 4 of the office action alleges that Gupta teaches applicability expressions 

and engineering requirements. However, claim 1 does not merely recite applicability 

expressions and engineering requirements. It recites "assessing applicability 

expressions, engineering requirements, and manufacturing availability to determine 

which instancings are available and valid for the different configurations; and 

generating the product definition based on all instancings that are valid and available." 

That is, claim 1 recites assessing the expressions, requirements and availability to 
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define a product definition. In contrast, Gupta and Cookson evaluate logical 
expressions to define a specific product. 

More generally, neither Gupta nor Cookson suggests a system that creates a 
product definition describing a collection of components for multiple possible 
configurations of a product and also details as to how the components are defined, 
developed, and manufactured (the callouts provide at least some of these details). 
Both Gupta and Cookson are silent about details as to how the components of a 
product are defined, developed, and manufactured. Gupta and Cookson might 
disclose systems that allow a user to configure and purchase a desktop computer on- 
line, but they do not disclose systems that, for example, can create product definitions 
for a commercial aircraft. 

The office action has not established prima facie obviousness of base claims 1 
and 21 . Therefore, all pending claims should be allowed over Gupta and Cookson. 

The office action also indicates that claims 1,4-18 and 21-30 are rejected under 
35 USC §101 for being directed to non-statutory subject matter. Page 6 of the office 
action alleges that base claims 1 and 21 do not positively recite the machine to which it 
is tied because only the preamble recites the use of a computer. The '101 rejection is 
respectfully traversed. The body of claim 1 begins after the word "comprising" as does 
the body of claim 21 . Base claim 1 recites "comprising using a computer to create a 
product definition." Base claim 21 recites "comprising using a computer to create an 
air vehicle definition." Thus, the body of each method claim is positively tied to a 
machine (computer). Therefore, the '101 rejection should be withdrawn. 
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The Examiner is encouraged to contact the undersigned to discuss any 
remaining issues prior to mailing another office action. 



Respectfully submitted, 



/Hugh Gortler #33,890/ 
Hugh P. Gortler 
Reg. No. 33,890 
(949) 454-0898 



Date: Nov. 30, 2009 



